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REMARKS 

This Preliminary Amendment cancels, without 
prejudice, claims 1-9 in the underlying PCT Application 
No. PCT/DE03/01627 and adds new claims 10-18. The new 
claims, inter alia, conform the claims to United States 
Patent and Trademark Office rules and does not add any 
new matter to the application. 

In accordance with 37 C.F.R. § 1.125(b), the 
Substitute Specification (including the Abstract) 
contains no new matter) . The amendments reflected in the 
Substitute Specification (including Abstract) are to 
conform the Specification and Abstract to United States 
Patent and Trademark Office rules or to correct 
informalities. As required by 37 C.F.R. 

§§ 1.121(b) (3) (ii) and 1.125(c), a Marked-Up Version of 
the Substitute Specification comparing the Specification 
of record and the Substitute Specification also 
accompanies this Preliminary Amendment. Approval and 
entry of the Substitute Specification (including 
Abstract) are respectfully requested. 

The underlying PCT Application No. PCT/DE03/01627 
includes an International Search Report, dated October 8, 
2003, a copy of which is included. The Search Report 
includes a list of documents that were considered by the 
Examiner in the underlying PCT application. 
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It is respectfully submitted that the subject matter 
of the present application is new, non-obvious, and 
useful. Prompt consideration and allowance of the 
application are respectfully requested. 



Respect ful ly Submitted , 



Dated: 4t>c 
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METHOD AND DEVICE FOR A VEHICLE-RELATED TELEMATICS 

SERVICE 



Background of tho Invention FIELD OF THE INVENTION 
The present invention relates to a method and a device for a vehicle-related 
telematics service with an action on at least one functionality in a motor 
vehicle via an air interface such as a mobile radio network or the 
communication via a bluetooth connection. One realization example of such a 
service is the remote diagnosis in the motor vehicle. 



BACKGROUND INFORMATION 

The proliferation of networked control units in today's motor vehicles offers 
10 more and more opportunities for influencing functionalities in the vehicle, for 
instance better diagnosis options in the case of a fault, or possibilities for 
remote operation of functions and/or components of the vehicle. Concepts are 
available in this context that allow reliable and secure access to the 
functionality in the vehicle across various distances using radio- 
15 communication-based intervention, for example, for performing reliable and 
high-quality fault diagnosis via remote diagnosis by a service center or via a 
remote diagnosis server having a corresponding diagnostic database. 
According to these approaches, communication systems integrated in the 
vehicle such as mobile phones and/or GSM-supported telematics-data 
20 terminals are utilized to transmit data between the control units connected to a 
vehicle network and/or components and the server of the service center. One 
proposal for such a system is described in German Patent Application No. DE 
100 26 754 A1. 754. A concrete realization of such a system or the respective 
server and data terminals is not indicated. 

25 

Summary of th e I nv e ntion 
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SUMMARY 

Utilizing a protocol that is already being used in the diagnosis of vehicle- 
control units for the implementation of a remote diagnosis has the advantage 
that the control units to be diagnosed will not need to be adapted to any other 
5 communication standards such as Internet communication standards, for 
example. The reason for this is that the service center communicates with the 
vehicle on the basis of the protocols utilized in the vehicle anyway. In this 
way, it is possible to provide remote-access possibilities even for current 
vehicles, without this requiring essential modifications of the control units. 
10 That is to say, the particular telematics service generally utilizes a protocol 
(application protocol in general) that is also used in the vehicle to implement 
the corresponding service locally. 

Particularly advantageous in this context is a gateway device, which is located 
15 inside the vehicle and is responsible for receiving and transmitting data via the 
air interface and for providing the additionally required security functions. 

It is particularly advantageous thatif the KWP2000 protocol, which is widely 
accepted as standard in the automotive industry, is utilized as protocol for the 
20 remote-diagnosis intervention. This protocol is used not only inside the 
vehicle, but is utilized also for the communication between the onboard 
component and the server in the distributed form of the remote diagnosis. 

By suitable implementation, the timing conditions to be observed inside the 
25 vehicle are taken into account in an especially advantageous manner and the 
dead time resulting from the air transmission is compensated. 

An especially advantageous feature is that complete messages are 
transmitted via the air interface, which are then fragmented in the vehicle or in 
30 the server in order to comply with the timing conditions of the utilized transport 
protocol. 

Further advantages are derived from the following description of exemplary 
embodiments and from th e d e p e nd e nt pat e nt c l aims . 
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Bri e f D e scr i pt i on of th e Drawing 

BRIEF DESCRIPTION OF THE DRAWINGS 
5 Hereinafter, the present invention is explained in greater detail on the basis of 
th e sp e c i f i c example embodiments depicted in the drawing.Th e f igures show: . 

Figure 1 shows an overall view of a system architecture for remote access^ 

10 Figure 2 shows a layer model of a gateway system in the onboard 

component of the remote-access system and a corresponding gateway device 
in the central component^. 

Figure 3 shows a flow chart of the message exchange between a control unit 
15 to be diagnosed and a service cente r; and, . 

Figure 4 shows a flow chart of this message exchange on the level of the 
transport protocols. 

20 D e scr i pt i on of th e Ex e mp l ary Embodim e nts 

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS 

Figure 1 shows an overall representation of a system for a vehicle-related 

telematics service, information being exchanged between a vehicle (at least 

25 one data terminal in the vehicle) and a server via a mobile radio network or 
via a data network such as the Internet. The system architecture for remote 
access shown in Figure 1 in the form of an overall representation is used in 
connection with functions for remote action, remote diagnosis, remote service, 
software download etc. Remote action or remote querying is 

30 e ss e ntial l y generaHv understood as the remote control of vehicle functions, in 
particular comfort functions such as turning on the parking heater etc. and 
querying vehicle statuses and/or operating parameters. In the process, the 
user initiates a communication with the vehicle via a central server, or the 
user communicates directly with the vehicle. Remote diagnosis includes the 
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remote reading out of diagnostic data from the vehicle, their analysis and 
possibly the generation of a recommendation regarding further steps. The 
analysis of the data and generation of the recommendation are performed by 
a central server, which is connected to the vehicle via a mobile radio network, 
5 via a wire-bound network and/or via a data network such as the Internet. Also 
to be mentioned as functions in this context is the so-called software 
download or remote flashing by which a new program code or new 
parameters may be loaded into software-configurable systems in the vehicle, 
such as control units, in order to improve their functionalities or their 

10 performance. Here, too, the communication is carried out via a mobile radio 
network, a wire-bound network and/or the Internet, for instance, going out 
from a central computer (server) or service center. Remote servicing is 
e ss e nt i a ll y g enerally the monitoring of the vehicle state and accessing of 
service data in the vehicle originating from a central location so as to check 

15 whether, when and which measures are implemented to maintain the setpoint 
state. One such example is the dynamic adaptation of service intervals. 
Overall, these functionalities are subsumed here under the term of vehicle- 
related telematics service. 

20 Figure 1 shows an overview of the system architecture for remote access. 
Shown as I are the control units, to be influenced via remote access, in the 
vehicle; shown as II are gateway devices for protocol transformation and for 
security functions; and shown as III is the data terminal on the service-center 
side such as a workshop tester, an operator console, etc. Onboard gateway 

25 device 104 is connected to a gateway device 100 of a service center by 

means of an air interface. Depending on the exemplary embodiment, this is a 
bluetooth interface, a GSM interface, a GPRS interface or some other type of 
interface. For a data exchange, gateway device 100 is also connected to data 
terminal 102 on the service-center side. This user terminal is either a 

30 workshop tester, an operator console or a similar device. In an alternative 
embodiment, the gateway device of the service center is not directly 
connected to the air interface, but, via a data network such as the Internet, is 
connected to a service provider whose server is in turn connected to the air 
interface. Depending on the exemplary embodiment, onboard gateway device 
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104 is a central gateway for the vehicle or a point-to-point gateway connecting 
a bluetooth interface or a GSM module, for example, to a CAN subnet of the 
vehicle. In the exemplary embodiment shown, which is also preferred in 
reality, gateway device 104 is a central gateway, which is configured to 
5 receive and transmit data via the air interface and which provides the 
additionally required security functions, if appropriate. On the other side, 
gateway device 104 is connected, via one or a variety of bus systems 106, 
108 and 110, to control units 112 through 124 to be diagnosed in vehicle 112. 
The buses are, for example, a comfort and vehicle-body bus such as a low- 

10 speed CAN or LIN bus, which interconnects control units for the air-condition 
system and the instrument cluster, and also an infotainment bus such as a 
high-speed CAN, MOST, fireWire bus etc., which connects the car radio and 
navigation systems, or a high-speed CAN bus or flexRay bus, which interlinks 
the control units for engine control, brake control, restraining systems, etc. 

15 Furthermore, a GSM module is connected to the gateway device (not shown 
in Figure 1 ) via a serial or parallel interface (for example UART), with whose 
aid the vehicle exchanges data with the service center. Gateway device 104 
may possibly also include a firewall by which the vehicle subnets are shielded 
from the outside. 

20 

Gateway device 100 on the service-center side e ss e nt i a ll y generally includes 
the same functions and elements as gateway device 104 inside the vehicle. 
The gateway device ensures the communication with data terminal 102 and 
operates the air interface. This pr e f e rr e d e x e mp l ar v example embodiment also 

25 includes a GSM module, which is operated by the gateway device via a UART 
driver. If provision is made for encryption of the transmission channel, the 
required encryption and decryptions are performed in both gateway devices. 
In addition, the two gateway devices include the required protocol 
transformations, i.e., the implementation of the received or transmitted data 

30 from the protocol of the air interface, such as the GSM protocol, into or out of 
the protocol of the vehicle system, such as the CAN protocol. 

For the communication of the two gateway devices with one another via the 
air interface a connection is established. This is a GSM connection in the 
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prof e rr e d e x e mp l ar v example embodiment, but different transport protocols 
are utilized in other embodiments. I t is essent i a l th e n that th e The system 
architecture shown in Figure 1 ytife eutilizes, for the message transmission^ a 
protocol that, in the diagnosis case, is also used in the diagnosis of the control 
5 units in the vehicle. Such protocols normally operate under certain timing 

conditions. The so-called KWP2000 diagnosis protocol, for example, is such a 
protocol that - possibly in modified form - is utilized in a multitude of 
applications in connection with motor vehicles. However, the subject matter 
described here is not limited to only the use of the specific KWP2000 protocol 

10 in the diagnosis, but is utilized in connection with other protocols and/or 

services as well. Narrow timing conditions must generally be observed in the 
motor vehicle. After establishing and authorizing a connection between the 
two gateway units, a message exchange is basically carried out on the basis 
of the utilized protocol. The gateway unit forwards messages arriving in the 

15 vehicle, such as KWP2000 request messages, to the control unit to be 
diagnosed and transmits its replies, such as the KWP2000 response 
messages, to the gateway in the service center. The service-center gateway 
operates in an analogous manner. In a preferred exemplary embodiment, 
gateway device 104 in the vehicle may also be directly connected to a testing 

20 device, which interacts with the control unit to be diagnosed on the basis of 
the same protocol utilized in the distributed application within the framework of 
remote action. 

It i smav be problematic that the diagnosis protocol used in the vehicle, such 
25 as the KWP2000, generally prescribes very narrow timing conditions with 
respect to the communication with the connected testing unit. If these timing 
conditions are not observed, the diagnostic procedure will be terminated. The 
timing conditions are so narrow that they are unable to be satisfied because of 
the transmission delay inherent in the air interface. Therefore, as described in 
30 the following, the synchronous connection between control unit and testing 

unit is decoupled in the illustrated distributed application and an asynchronous 
connection provided via the air interface. In the process, the synchronous 
connection, in this case between gateway device and control unit to be 
diagnosed, is maintained inside the vehicle system, and possibly on the 

878915V1 6 MARKED UP COPY OF THE 

SUBSTITUTE SPECIFICATION 




service-center side as well, where a synchronous connection may exist 
between service-center gateway and testing unit. On the other hand, the air- 
interface connection is asynchronous and does not adhere to the timing 
conditions of the utilized diagnosis protocol, but instead complies only with the 
5 timing conditions of the protocol used there. The gateway device in the 

vehicle and/or that in the service center is therefore configured in such a way 
that it controls the connection to the service center on the one hand and the 
time-critical connection to the control unit to be diagnosed on the other hand. 

10 Figure 2 shows a layer model of gateway device 104 in the vehicle. Gateway 
device 100 in the service center is configured accordingly. Gateway device 
104 in the vehicle integrates all required layers of a communication system for 
the linking of at least one vehicle subnet and for communicating with a service 
center via an air interface. In the exemplary embodiment shown in Figure 2, 

15 gateway device 104 connects a total of three vehicle subnets, 106, 108 and 
110, which were already shown with the aid of Figure 1 , and integrates a 
GSM-protocol stack for the data exchange with a service center. The layer 
model describes communication system I and application system II of the 
gateway. In the preferred exemplary embodiment, subsystem drivers 106a, 

20 108a and 1 10a, preferably CAN drivers, are provided in the bottom layer of 
communication system 1 for each vehicle. Superordinate to the drivers, as 
second layer, is a CAN network layer 126, which implements the messages 
received from the various subsystems and which are to be distributed to 
particular subsystems or to the air interface. The network layer is in charge of 

25 in-vehicle routing of messages, which are CAN messages in the exemplary 
embodiment. Above the network layer is the transport-protocol layer, 
preferably the CAN transport-protocol layer, which is assigned to the 
individual subsystem. This transport protocol is required to transmit messages 
that are longer than the maximum data length of the subsystem messages, 

30 which is longer than 8 data bytes in CAN applications, the transmission being 
carried out via the individual subsystem. Located in application system II are, 
for instance, security services 128, which are responsible for encryption, 
authentication and authorization of remote access. Remote services 1 30, 
which the vehicle offers to the outside, are located here as well. These are, for 
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example, remote-diagnosis services, remote-control services, remote-service 
services, software-download services, etc. All inquiries via the air interface are 
always forwarded to one of these remote services. This remote service 
decides whether a message will be forwarded within the vehicle. Due to this 
5 coupling in the application system, it is possible to satisfy the most stringent 
security demands. If the gateway itself is able to be diagnosed, diagnosis- 
assistance service KWP2000 will also be utilized in addition to diagnosis 
application 132. Apart from the mentioned elements, the vehicle gateway also 
includes a network management as well as local and global management of 

10 the operating states and also the system diagnosis, which will not be 

discussed further in the following. Moreover, a real-time operating system 
(such as an OSEK-conforming OS) and a monitoring module (134) are 
provided. For the operation of the air interface, gateway 104 also includes a 
GSM transport protocol, a GSM network layer 136 and a UART driver 138 as 

15 well, which is connected to a GSM module via an SPI interface 140. 

Gateway device 100 in the service center is configured accordingly. It couples 
from GSM to a subsystem, preferably a CAN, and vice versa. Here, too, a 
GSM module is therefore connected to a UART driver 144 via an interface 

20 142. Superposed is a GSM network layer 146 and a GSM transport protocol. 
Security services 148 correspond to those in vehicle gateway 104. A service 
tester 152 or a console is connected via a CAN subsystem 150. Here as well, 
the CAN connection is provided via a CAN transport protocol, a CAN network 
layer 154 and a CAN driver 156. The coupling from GSM to a CAN bus 

25 system in the service center permits the direct connection of diagnostic tester 
1 52 or the forwarding of the data to a PC, which evaluates them accordingly. 
If remote-diagnosis data are to be made available via the Internet, a coupling 
to IP-based protocols will be performed in gateway 100. In another 
embodiment, the diagnosis results are recorded in a database in the service 

30 center and then made available to a service on the Internet. The mapping to 
an IP-based communication is always carried out at a central location in the 
service center and not in each vehicle. 
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The remote service 'remote diagnosis' is shown in Figure 2 in 130 as left oval. 
This application includes programs that are configured in such a way that they 
decide upon arrival of a diagnosis request whether this request is meant for 
self-diagnosis of the gateway or whether it is meant for a control unit located 
5 at one of the connected buses. A table is provided for this purpose in which 
the control-unit configurations of the vehicle (such as identification number, 
fault memories to be read out, etc.) are listed and on the basis of which the 
arriving message is conveyed to the appropriate bus. When changing the 
control-unit configuration, this table must therefore be adjusted as well. 

10 

As mentioned before, a diagnosis protocol, which works within tight time 
frames, is utilized for diagnosing the individual control units in the vehicle. 
Furthermore, the bus systems utilized in the vehicle usually have a limited 
message length. As a ru le Generallv , the messages provided in the diagnosis 

15 protocol have a maximum length that deviates therefrom. For instance, a 

maximum length of 255 bytes is currently provided for KWP2000 messages, 
whereas the CAN protocol utilized in the vehicle is limited to 8 bytes. 
Furthermore, a transport protocol, which includes several timing conditions in 
the range of a few milliseconds, is integrated in each control unit to be 

20 diagnosed via KWP2000 and CAN. The transmission delay via GSM amounts 
to at least 600 milliseconds. For this reason, a transparent transmission of 
CAN messages from the control unit to be diagnosed to the service center is 
not possible, so that the use of a special transport protocol inside the gateway 
device cannot be avoided. Depending on the design, it must perform a time 

25 decoupling and/or an adaptation of the data lengths. The peer entities of the 
transport layer in the security gateway of the vehicle are responsible for 
compliance with the timing conditions in the transport layer of the control unit 
to be diagnosed, and the transport layer in the gateway of the service center 
correspondingly ensures compliance with the timing conditions in the peer 

30 entities of the transport layer of the tester. Furthermore, the transport layer in 
the gateway adapts the data lengths by fragmenting or defragmenting the 
data. Any transport protocol may be used to transmit complete messages 
such as KWP2000 messages via GSM. 
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Figure 3 shows a flow chart representing the message exchange between the 
participating components in the utilization phase of remote diagnosis for the 
used diagnosis protocol KWP2000. 

5 Shown is the message exchange between the service center (such as tester 
200), gateway 100 of the service center, gateway 104 of the vehicle and 
control unit 202 to be diagnosed. As a first message, originating from tester 
200 by way of gateway 100, a KWP2000 message is sent via the air interface, 
which brings the control unit to be diagnosed into diagnosis mode once the 

10 message has been forwarded by gateway 104. The service center transmits 
the KWP2000 messages between the gateways via the GSM connection in 
transparently encrypted form. The implementation of the message onto the 
other protocols takes places in the transport layers of the gateway. This is 
followed by cyclical, so-called tester-present messages, which originate from 

15 the tester and are required to keep the control unit to be diagnosed in 

diagnosis mode. As soon as the control unit to be diagnosed is in diagnosis 
mode, the actual diagnosis will begin during which messages with useful data 
are transmitted from the service center to the control unit and vice versa 
(KWP2000 diagnosis- request messages as well as KWP2000 response 

20 messages). 

The latter is illustrated in the flow chart of Figure 4 which, using the example 
of an exemplary diagnosis request and the associated response, shows the 
data exchange between tester 200 and control unit 202 via the air interface 

25 and the corresponding gateways on the level of the transport protocols. The 
decoupling via the transport protocols can be clearly gathered from this 
illustration. No individual CAN frames, but complete KWP2000 messages, are 
sent via the GSM path. If appropriate, these are encrypted prior to 
transmission via the air interface and decrypted upon reception. Thus, the 

30 CAN frames are defragmented in gateway 100 prior to transmission and the 
entire diagnosis-protocol message is fragmented into CAN frames in vehicle 
gateway 1 04, or vice versa in the case of a response. The message of the 
diagnosis protocol generated by the operator or the sequence program of 
tester 200 is transmitted via the CAN connection to gateway 100 in CAN 
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frames 204, 206, 208 and 210. The transport layer in gateway device 100 
handles return messages 212 and 214 required within the framework of the 
timing conditions of the data exchange between tester and gateway. 
Furthermore, the transport layer of gateway device 100 defragments the 
5 arriving messages and transmits a long, assembled diagnosis message 216 
via the ISO transport protocol, using the GSM interface. Gateway device 104 
receives this message, its transport protocol fragmenting these messages 
again and transmitting them as individual CAN frames via the CAN bus to 
control unit 202 to be diagnosed (messages 218, 220, 222, 224). 

10 

Furthermore, the transport layer of gateway device 104 and also the 
corresponding transport layer in the control unit to be diagnosed ensure the 
timing conditions of this communication by transmitting acknowledge signals 
226, 228. A corresponding procedure is used when transmitting data from the 

15 control unit to be diagnosed to the service center. Here, too, the long 

diagnosis message 230, which is then transmitted via the GSM connection, is 
transmitted in individual fragments 228, 230, 232, 234, 236 from the control 
unit to be diagnosed to gateway 104. The transport layer there converts these 
fragments into the diagnosis message and transmits acknowledge signal 238 

20 to comply with the timing conditions. The complete diagnosis message is then 
transmitted to the service center (gateway 100). The transport layer of 
gateway 100 fragments the received message and transmits it in fragments in 
accordance with the transport protocols of the tester to the tester (frames 240, 
242, 244, 246, 248). The transport layer of the tester ensures compliance with 

25 the timing conditions by acknowledge signal 250. 

The afore-described procedure I smav be used in all vehicle-related telematics 
services having remote action in which the mentioned preconditions are 
satisfied. 
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A method and a device for a vehicle-related telematics service are provided, 
the same application protocol being utilized for the telematics service both for 
5 the air interface and for the communication in the vehicle and possibly in the 
service center. 

(F i gur e 2) 
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